I.FHIR概要

02 FHIR 基礎

FHIR想要解決的最核心問題是不同單位之間，資料結構、資料內容與建置系統的不統一，
這套標準不僅適用國內，也適用國際間的資料交換
對於大多數醫療院所來說，他們的醫資系統大多是 (1).自主開發 (2).廠商外包，
但無論是哪一個路徑，系統勢必會長的不太一樣，產出的資料格式、欄位、資料定義也都不盡相同，

在現有的架構下如果想要將兩個單位的醫療資料交換，無非是開發一個資料交換介面，
或是回歸最原始的紙本互傳登打，
可以想像到的是，無論是走開發介面或是紙本交換，在執行面上都非常沒有效率且造成諸多誤差與浪費。

與醫療業非常相像的處境可以看到金融業，過去國際間的資金往來都是透過電匯，
匯款人將錢支付給當地電報局，電報局收到錢之後通知對方的電報局
兩方的接線員再將密碼授權給受款人以發放資金，對於各金融單位而言，
身分確認與資金流動受制於這樣的傳送機制，會非常沒有效率，

在這樣子的背景之下制定了SWIFT標準，統一了訊息傳送的平台、
驗證加密的系統與資料的標準來解決資料互通造成的冗餘成本。

以現況來看，醫療業也亟需一個標準來統合各醫療單位的資訊落差，
且這個標準需要能夠包含照護、給付等周邊領域，於是FHIR應運而生。

FHIR其實在2011年就已經被提出，開始受到比較大的關注來自於Covid-19疫情後，
人們發現遠距醫療成為了現代醫療服務中不可或缺的一環
也因此要有完整可用的資料標準，讓資訊介接變得更加容易。

FHIR 現在最新的正式版本為R5，台灣目前官方使用的版本為R4.01，不同版本間會有定義的差異，
HL7預估最快在明年可能會提出R6版本，本篇文章將主要使用R4.01版本介紹。

那麼，FHIR相較以往的醫資標準有什麼優勢？

1. 可讀性：FHIR同時保留了給醫資系統讀取的代碼欄位與給人類閱讀的文本欄位，
   且結構化設計資料欄位讓不同屬性的資料內容區分開來，在交換資料上具有很強的人類可讀性。

2. 通用性：因為採用RESTful API來做資料交換，基本上所有的裝置、作業系統或應用程式都能兼容使用

3. 適應性：FHIR提供了Extension作為可擴展項內容的一環，可以做為基本欄位的補充；
   而單位可自行撰寫、發布實作指引(Implementation Guide，簡稱IG)自訂各資源的使用目的及客製化資源內容

4. 安全性：在安全性上採用了OAuth 2.0認證，能夠保障個人醫療資訊的隱私和安全

5. 結構化：FHIR將與醫療有關的所有元素都定義為統一的資料結構，
   特定資源的組合(set)可以做為描述一個特別用途的醫療事件，
   這也降低了傳統醫資系統建置前期的規劃成本

前面說了FHIR這麼多的好處了，但是回頭盤點一下，
各醫院當前的內部系統、機台、行政作業都還圍繞著各院自己的HIS系統，
且HIS內擁有過於龐大且個別定義的醫療資料，在現行比較可行的方法是針對特定事件，
由各醫院從HIS中抽取出需要的資料來整理成FHIR格式，
若是要將HIS的底層資料翻新成FHIR，在各個方面需要的更新成本都非常恐怖，
最終還是取決於醫療院所願不願意往FHIR化這方面前進。

然而，衛福部已開始推行FHIR標準的導入，對於各醫療院所來說是非常沉重的壓力，
無論是從HIS中抽取FHIR所需的資料，又或是組合成FHIR格式的資料
每一步都是Hardcoding，除此之外，由於資訊專業人員不一定理解(通常不會)醫學專業知識與使用術語，
遇到FHIR格式內需要提供標準術語代碼時，
只能靠猜，以台灣的背景來說，甚至醫事人員也不一定有這些術語代碼的使用或學習經驗，
這使得光是要"湊"出來一張FHIR的單張都要費盡洪荒之力。

FHIR 基礎概念

FHIR把所有的資料，事件都整理成統一的資料結構，對應不同的資料內容使用不同的資源(Resource)，
因為每個Resource的功能或用處不太一樣，多個不同的Resource經過特定的Resource打包可以作為一個申請提交表單的使用。

Resource是組成FHIR的基本單位，而Resource本身也有層級高低的區分，根據hl7對FHIR的介紹，類似於網路層架構那樣，Resource依照抽象化的程度被分為了5層
層級越高則代表其抽象化程度越高，也就代表其越接近使用用途。

層級概分

 Level 1 :
Foundation -> Base Document, XML, Json...

 Level 2:
  Implementer Support
  Security & Privacy
  Conformance
  Terminology
  Exchange
 
 Level 3:
Administration

 Level 4:
Clinical, Diagnostics, Medications, Workflow, Finacial

 Level 5:
Clinical Reasoning

EX: 一張保險申請表單 Bundle Resource，是由一個Composition Resource當作標頭，
展示這個Bundle Resource中是由哪些Resource組成的，
而Composition中清楚標明了
病患的基本資料 Patient Resource、
病患的保險狀態 Coverage Resource等引用。

由上面這個例子可以大概看得懂他們的關係

 - Bundle
  - Composition
   - Patient
   - Coverage
   - ...(others)
 
這樣子的架構讓各個Resource的使用範圍跟用途會變得很清楚，
就跟蓋房子一樣，有鋼筋、水泥跟防水隔熱層，最後這些工程結構統包整合成能住人的建物。

此外，根據不同版本的FHIR，這些Resource的骨幹定義是會隨著版本更新，
Resource內含有的欄位會定義得更加清楚，各個Resource會標示其成熟度，
由高至低分別是
Normative -> FMM 5 -> FMM 4 -> FMM 3 -> FMM 2 -> FMM 1 - Draft(0)

如果有要照hl7提出的FHIR 基本Resource來開發實作指引(IG)的話，要特別注意可以實作的定義範圍

此外，前面提到的，FHIR提供了Extension作為可擴展項內容的一環，可以做為基本欄位的補充；
但如果你的實作範圍是遵照某些實作指引IG來開發的話，IG publisher才有權限可以制定Extension的使用範圍，

也就是說，
FHIR hl7總會制定了FHIR的基本骨幹，Resource的基本定義、使用範圍等
各個國家的主管機關為了投入使用FHIR，會參考hl7總會制定出來的FHIR定義，
在他們國家先制定出一個核心實作指引(Core IG)
這個Core IG的意義是因為每個國家的國情、文化與需求不同，
主管機關先將總會的FHIR Resource基本定義先擬出一個適用於該國家的版本，
在完成Core IG後，各機關或公司企業再依照他們各自的需求，參考Core IG去制定符合他們需求的實作指引IG，
這個子IG(以下簡稱IG)實際上就是資料交換者或使用者應該要按照這個IG定義的標準或限制，
來填入這些受交換方所需要的欄位，
屆時才能以這個IG標準和對方互換他們所需的資料內容。

制定的workflow大概像是:
 先定義了Core的表單IG欄位，去參考其他核心的欄位
 然後找臨床使用者跟來討論，對表單增減修改來成為模板的架構

以末端而言，大多數的醫資軟體業或醫事機構的資訊人員在處理的不外乎兩個部分

1. IG的制定與發佈
2. 將資料規範於IG的格式要求並進行交換

在台灣的例子來看，制定IG的單位目前基本上都是主管機關衛福部及其下轄機關，主要的使用場合是將原有的健保申請或公衛資料上傳方式改變為FHIR
以符合政策需要。也因此本篇系列文會主要拿健保癌症用藥事前審查TWPAS IG來做範例，這也是目前中央健保署制定的相對完備的IG，可以提供很好的實作學習機會。

下一篇文章會開始談到FHIR的其他基本概念。